lsx? lasx? oh dear.

lsx? lasx? oh dear.

LSX is a 128-bit vector extension, and LASX is a 256-bit vector extension. Parameters and return values for neither of these data types are passed through vector registers. 😃

Then why is the lint triggering?

Here is the uses_vector_registers check.

It looks fairly dubious to me. https://github.com/rust-lang/rust/blame/bfe809d93c67de03e3a84b80549927fd828ec5d0/compiler/rustc_monomorphize/src/mono_checks/abi_check.rs#L43

This is not the correct fix, the correct fix is to fix the lint itself.

Here is the uses_vector_registers check.

It looks fairly dubious to me. https://github.com/rust-lang/rust/blame/bfe809d93c67de03e3a84b80549927fd828ec5d0/compiler/rustc_monomorphize/src/mono_checks/abi_check.rs#L43

I see it. But I'm not sure how to make it more accurate.

Here's a case:

#![feature(stdarch_loongarch)]
use std::arch::loongarch64::*;

pub unsafe fn simd(s: i32) -> u32 {
    lsx_vpickve2gr_bu::<0>(lsx_vreplgr2vr_b(s))
}

and the PassMode is

Direct(ArgAttributes { regular: , arg_ext: None, pointee_size: Size(0 bytes), pointee_align: None })

BackendRepr is

Vector { element: Initialized { value: Int(I8, true), valid_range: 0..=255 }, count: 16 }

Is it true that the Rust frontend cannot determine whether a parameter is passed through a vector register or a general-purpose register based solely on PassMode and BackendRepr? @veluca93 This decision is made by the LLVM target backend. If so, adding ABI checks to LoongArch is also a valid solution, and at least harmless.

My understanding is the frontend technically cannot precisely control it, no.

Since we cannot determine the type of registers used for vectors in Rust's front-end, I have reverted the return type of features_for_correct_vector_abi to Option. A return value of None indicates that the given target does not use vector registers for vectors.

Do you think this is ok? @workingjubilee

Hmm.

What we want is to both

• understand what the C ABI uses
• understand what is possible at the level of codegen and the machine ISA, because we also need to do codegen correctly for intrinsics and other, non-C ABIs

If the backend does not expose some ability to handle register usage (which does imply that we should have a nonzero ability to get it wrong), then I think we will simply fuck things up in a different way from our current approaches.

In either version of this PR that I have seen so far, it adjusts things in a way that fixes things for the C ABI in certain conditions. However, the motivation¹ for the changes are that our current compiler contract with the Loongarch backend remains poorly-specified and poorly-understood.

• The first version proposed, accordingly, seemed to just assuming that our compiler contract is similar to the contract with the other backends, when it apparently is not?
• The second version proposes surrendering to the whims of the codegen backend, in a way which may be technically correct but leaves us in the dark as we head into the future.

So, before I merge any fixes, I would like to understand, relative to how the Loongarch backend handles the LLVMIR lowering,

• what we can do
• what the effects of those choices are
• what we should be doing